OBSERVATION: An explicit form for a class of second preimages for any message M for the SHA-3 candidate Keccak

In this short note we give an observation about the SHA3 candidate Keccak[r, c, d], where the parameters r, c and d receive values from the formal proposal for the Keccak hash function (with the hash output of n = c 2 bits). We show how an attacker that will spend a one-time effort to find a second preimage for the value z0 = Keccak[r, c, d](0) will actually get infinite number of second preimages for free, for any message M . Our observation is an adaptation of similar attacks that have been reported by Aumasson et.al and Ferguson et.al for the SHA-3 candidate CubeHash. By this observation we do not contradict security claims present in the official Keccak submission, but we allocate a property in the design of the function: we get an explicit form for a class of second preimages for any message M . As far as we know, this kind of property is not known neither for MD5, SHA-1, SHA-2 nor the other SHA-3 candidates. 1 Description of the observation Hash function designs based on sponge functions are recent design concept invented in 2007 by Bertoni, Daemen, Peeters and Van Assche [1]. The design concept has attracted big interest by cryptographic hash designers and in the ongoing SHA-3 competition there are four sponge (or spongelike) designs. As an introduction to this note we want to recall the remark that sponge function designers have written in their paper [1]: “More recently, a series of attacks [9, 10, 5, 12] has shown that certain hash function constructions do not offer as much security as expected, leading to the introduction of yet other criteria, such as chosen target forced prefix preimage resistance. As was already predicted in [1], there is no reason to assume that no new criteria will appear, so the design of a hash function seems like a moving target.”. In this observation we will show one property that is present in sponge function designs based on permutations, and as far as we know it is not present in other hash designs (like wide-pipe or narrow-pipe MerkleDamg̊ard designs). From the point of view of the “moving target” that sponge designers were talking about in their paper, it seems that one property present in older designs (MD5, SHA-1, SHA-2) that we took for granted and there was no attempt to define it precisely as a property (or requirement) is not present in sponge function designs based on permutations. Fig. 1. One time effort of 2× 2 = 2× 2 calls to the permutation f and its inverse f−1 in order to find the messages P1, P2, P3 and P4 that give collision in the part C2. This computational effort is independent of the messages that will be attacked afterwards. Namely, the essence of the observation is the following: If we are requested to find a second preimage of the zero message 0r for the hash function H (where H is any hash function from the set {MD5, SHA-1, SHA-2 } we will need approximately 2n calls to its compression function. This effort should be non-correlated with our efforts to find the second preimage for the hash H(M) of another message M i.e. for finding that second preimage we will need again 2n calls to the compression function. However, in this observation we will show that for the the Second Round SHA-3 candidate Keccak[2] an attacker that will find a second preimage of the message 0r will have for free second preimages for any other message M . We will consider the official variant of Keccak[r, c, d], where the parameters r, c and d receive values from the official proposal for the Keccak hash function and where the hash output is n = c 2 bits. Our observation is in fact based on the observations and attacks in [3] that Aumasson, Meier, Naya-Plasencia and Peyrin did against CubeHash[4] hash function and on attacks in [5] that Ferguson, Lucks and McKay did also against CubeHash hash function. The idea is presented in Figure 1 and the goal is to find one internal collision in the part that has c bits (the part that represents the capacity of the hash function). More concretely, we want to find two r-bit messages P1 and P3 such { f [r + c](P1||0) = (P2||C2), f−1[r + c](P3||0) = (P4||C2). (1) If the design of the permutation f is such that it behaves as a pseudorandom permutation, then finding the required collision will need approximately 2× 2c/2 = 2× 2n calls to the permutation f and its inverse f−1. However, this effort can be performed independently of the messages for which we will launch afterwards a second-preimage attack. Now, once we have found the messages P1, P2, P3 and P4 let us investigate how many second preimages we have for the hash value z0 = Keccak[r, c, d](0r). Proposition 1. The message P1||(P2 ⊕ P4)||P3 is the second-preimage for z0 = Keccak[r, c, d](0 r). Proof. For digesting the message 0r we have the following iterative process: Keccak[r, c, d](0) Initialization and padding S (1) 0 = 0 , M = 0||PADDING ≡ ≡ 0|| (0x01||byte(d)||byte(r/8)||0x01||0x00||...||0x00) } {{ } r bits ,